This invention relates to the dynamic sharing of user interfaces and user interface components by more than one application. More particularly, it allows an application developer to provide an application with a user interface that is independent of any particular window management system.
An application interacts with a user via a user interface. A graphical user interface (GUI) allows a user to interact with a computer using graphics, images, data and text together with some form of pointing device. The GUI is an improvement over the traditional text display and alphanumeric keyboard input device. One of the more popular pointing devices used by a GUI is the mouse. The mouse input device complements the keyboard which can be used for traditional text input and display. The GUI's graphical images are chosen to be intuitive for ease of use, such as a push-button labeled with the image of a file cabinet to denote the action of saving a file. Individual components of the graphical user interface, such as a particular window or a push-button, are selected by using the mouse or any other supported pointing device. Other pointing devices include tablets, touch screen, touch screen overlays, track balls, joy sticks, light pens, thumb wheels etc.
A window management system provides many of the important features of modern user computer interfaces. A window management system allows multiple applications to interact with the user on a single computer display, and provides low level functions for the application to display data and collect input from the user. The window management system permits application programs to show results in different areas of the display, to resize the screen areas in which those applications are executing, to pop-up and to pull-down menus. The window management system is a resource manager in much the same way that an operating system is a resource manager, only the types of resources differ. The window management system allocates the resources of screen area to various applications that seek to use the screen and then assists in managing these screen areas so that the applications do not interfere with one another. The window management system also allocates the resources of interaction devices to applications that require a user input and then routes the flow of input information from the devices to the event queue of the appropriate application for which the input is destined.
The look and feel of the user computer interface is determined largely by the collection of interaction techniques provided for it. Designing and implementing interaction techniques for each individual application would be a time consuming and expensive task. Furthermore, each application would end up with a different look and feel making it difficult for a user to move from one application to another. Applications sharing a common window management system can utilize a common interactive technique toolkit built for the window management system to assure a common look and feel. An interactive technique toolkit consists of a set of subroutines that provide different types of display objects.
Interactive technique toolkits, which are subroutine libraries of interaction techniques, are mechanisms for making a collection of techniques available for use by application programs. By using interactive technique toolkits, a consistent look and feel among application programs sharing a common window management system can be insured. Using the same toolkit across all applications is a commonly used approach for providing a look and feel that unifies both multiple applications and the window environment itself. Interactive technique toolkits are available for specific windowing management systems. For instance, the menu style used to select window operations should be the same style used within all applications. Basic elements of the toolkit can include menus, dialog boxes, scroll bars, file selection boxes and the like, all which can be conveniently implemented in windows.
As previously stated, applications that use a windowed graphical user interface often want to have an identical look and feel for functions that appear in different application contexts. Often these functions are only needed on demand, as the result of a user selection within the GUI. The use of interaction toolkits can be used to partially meet these goals but, have several drawbacks.
The first drawback is that the display objects are completely incorporated into each application program. Many applications share many of the same user interface features and display objects. Currently, each application contains all display objects for its user interfaces. That is, each application contains the sequence of calls to the window management system for generating each display object. Although many applications share the same display objects, each application must contain the calls for generating each particular display object. This replication requires the use of additional space for each replicated object and creates maintenance problems. When the same display object is modified in some way it must be modified in all applications that contain the display object.
For example, OSF/Motif.RTM. toolkit provides a FileSelectionBox "Widget" that provides for creation of a File Selection Box. The FileSelectionBox "Widget" is made part of the application program when the application program is created by copying the appropriate widget and code to customize it from the appropriate subroutine library. The code, a sequence of underlying window management system commands, for the widget is copied to the application program and becomes a part of the application program. Thus, each application program that utilizes this widget is compiled with the widget as a part of the application code. Since the widget code is incorporated into the application code a subsequent change to the widget definition in the interaction toolkit (i.e., a change in the underlying sequence of window management system commands) requires modification of all applications that use the widget. Although interaction technique toolkits provide for sharing of certain display features such as widgets, they pose substantial maintenance problems. All instances of the copied code must be identified and uniformly modified if the common look and feel is to be preserved. This problem is compounded when the application program's source code is not available as with many application programs.
A second drawback is that all the code for generating display objects of the application must be contained in the application regardless of their likelihood of use. Suppose a GUI for a given application consists of a hierarchically related set of windows and the application allows the user to traverse through or select a given window from a main window. Certain windows in the hierarchy are not going to be seen by the user in the course of a session. For instance, in a word processor application, the set printer parameters window will in most cases be executed only rarely. Using an interaction toolkit, however, all the code for generating display objects including those that are rarely shown to the user are contained in the application. This is because the application program contains its own copy of the code that creates any display objects and their associated data structures. This can cause a great deal of memory to be used by a single application. Memory is at a premium with most window management systems, so that any increased use is costly in terms of system performance.
A third drawback is that applications must be partially rewritten in order to assure that their user interfaces operate on a different window management system. The window management system specific portions of the application need to be adapted to the new windowing system or the new window management system implementation. Limitations of the old or new window management system may result in a change in the look and feel of the application.
Currently many applications have user interfaces that are written for a particular window management system. For example, a word processing application written to run under WINDOWS.TM. window management system will not run under X WINDOWS. The word processing application would need to be at least partially rewritten in order to run under X WINDOWS. These changes can be costly in terms of time and money. It also leads to the need to maintain two different versions of the word processing application, one for WINDOWS and one for X WINDOWS. With several window management system specific implementations of the same word processing application there is also the potential that the "look and feel" of the application will change across these implementations. These problems are compounded when a developer offers a variety of associated applications such as word processing, spread sheet, graphics programs, data base programs, grammar checkers, spell checkers etc.
A fourth drawback is that sharing is only permissible on a very low level. Returning to the X windows OSF/MOTIF example explained above, it is clear that interactive toolkits provide for the use of similar widgets across applications by replicating the widgets into each application. However, these widgets are low level display objects. Applications may have more than just widgets in common. For instance, several different applications may contain a printer setup interface or series of windows for setting up or adjusting the printer. The printer setup interface constitutes a collection of display objects that are shared by multiple applications. However, the interaction toolkits do not provide for sharing at this level unless it is by sharing the common code via replication of the code in each application. The sharing of common code has drawbacks previously mentioned. Also the printer setup interface would have to be rewritten if the application is to be used with other window management systems.
A fifth drawback is that most window management systems do not provide for support of interpretive applications. Some applications run in an interpretive mode. These applications are compiled and run on the fly. Most window management systems do not support interpretive applications. Most window management system only provide for interaction via a compiled subroutine library. Thus, interpretive applications must provide a mechanism for translating the application user interface display commands to a compiled subroutine call.
Several alternatives have been proposed to overcome these drawbacks. One alternative is to replicate the common sub-hierarchy of display objects in each user interface as it is stored in a display object store. Unfortunately, while this is only mildly inefficient during initial application development, it poses substantial maintenance problems. All instances of the copied common sub-hierarchy must be identified and tracked if a common look and feel is to be preserved across all applications. Maintenance also becomes an issue because changes must be propagated to all instances of the common sub-hierarchy.
Another alternative permits sharing of common sub-hierarchy of display objects at the display level. The applications share a single instance of the common sub-hierarchy at runtime. If this is done without sharing at the user interface display object store level, all the maintenance problems of the previous alternative still apply. If sharing is done at both the display level and the user interface display object storage level, the application no longer has separate objects at the display level that can be controlled and modified independently of the duplicate sub-hierarchy that is displayed. The applications could not then individually tailor or modify the common display object shared during runtime.
Still another alternative is to reference the common sub-hierarchy of display objects from a display object store instead of from the application. This is accomplished by storing a reference to the display object store that indicates the common sub-hierarchy that is to be shared. Unfortunately, this results in fixation in the display object store of the overall user interface hierarchy for a given application. Thus, the application losses dynamic control of the user interface.
A further alternative is to extract the common sub-hierarchy of display objects, creating a separate user interface in the display object store. This new user interface can now be included in a loaded interface, given a user interface server that provides such a function. This, however, requires changes to the original interface, to remove the sub-hierarchy, and changes to the applications, which now have to include the separate sub-hierarchy. Additional difficulties occur when user interfaces share sub-hierarchies which are not identical, but have some overlap. This results in either extracted sub-hierarchies with some duplicate components that have to be maintained synchronously, or multiple levels of extracted sub-hierarchies to arrive at least common denominators of display objects. Both of these results are difficult to manage, and the latter means more changes to applications as their user interfaces evolve.
For the forgoing reasons, there is a need to provide for the dynamic sharing of user interface components.